home *** CD-ROM | disk | FTP | other *** search
- Path: nntp.teleport.com!sschaem
- From: sschaem@teleport.com (Stephan Schaem)
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,in,comp.sys.amiga.advocacy,comp.sys.amiga.hardware,comp.sys.amiga.misc,comp.sys.amiga.graphics
- Subject: Re: AB3D II beats Quake....
- Followup-To: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,in,comp.sys.amiga.advocacy,comp.sys.amiga.hardware,comp.sys.amiga.misc,comp.sys.amiga.graphics
- Date: 3 Apr 1996 20:46:44 GMT
- Organization: Teleport - Portland's Public Access (503) 220-1016
- Distribution: world
- Message-ID: <4juo3k$n44@nadine.teleport.com>
- References: <4jov37$i1g@nadine.teleport.com> <2965.6666T798T1982@mbox.vol.it>
- NNTP-Posting-Host: kelly.teleport.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Fabio Bizzetti (bizzetti@mbox.vol.it) wrote:
-
- : >: Imagine this.. I need a fast small polygons routine, and call the API.
- : >: When the polygons are 2, it's ok, but when they're 20000, 99% of CPU time
- : >: is wasted just only in the function call.
-
- : > Then you use a count that is not #1
-
- : > DRAW_Polygon(long count,ppolygon polygon);
-
- : > Here, 1 call to render 4 billion polygon....
-
- : >: Avoiding it and using inline code is already hardware banging.
-
- : > BTW, calling a function on the amiga is jsr/jmp/rts . now compare to
- : > the amount of processing done with the polygon setup routine its minimal.
- : > But its there... thats why the Amiga OS need a redesign, in my view.
-
- : > Stephan
-
- : Sorry, but I dont wanna describe how my 3D sprites routines work, and it's the
- : best example of an advanced routine that cannot be made with the method you
- : describe. And anyway, should I lose my (c) to give it for free so it can be
- : put into the API? I repeat, it's a lot hardware dependent anyway (AGA version
- : is specific).
-
- I was not talking about your "3d sprites", but about OS call overhead...
- HW without API is good for video games only, since they will probably
- die before the HW become old. But for a REAL system designed to do more
- then game you do need a well designed open API. The HW come second, or
- even a few years after the OS is up and running.
-
- : P.S: sorry, but with "lotsa polygons/sec routine" I didn't mean a standard
- : API's polygon routine, but the last "pre-calculated" state of the art routine
- : (with limit in dimensions of polygons, etc.. all in tables) that, to work with
- : an API, must be included in the API itself. Well, will we get an API of 1000Mb
- : soon, will the revolutionary methods must become PD to be included in the API?
-
- Including hacks in an API is not too cool, But you can do hacks like that
- with the low level devices of the API. the API is basicly here to take
- care/offer general functions (in growing numbers: a new low level device
- might mean adding new set of API functions) of the various low level
- device that offer various functionality.
-
- #1 I want the lowlevel device to be 100% open to the HW it drives, and
- very well optimized for its interface with the API.
-
- If you notice this as nothing to do with amiga OS running on PC, but
- the amiga OS itself. I see the HW as something down the road, something
- that evolve... and because of this the OS should be totaly open to new
- HW and make efficient use of it.
-
- : The API just gets all the fastest games' methods, get the sources, and make
- : a single all-comprehensive API that is simply all the code ever written put
- : together? When someone writes a new Amiga game to make innovations, he invents
- : a new method and he should (before he releases the game) write the new part
- : of the OS's API, thus write drivers to get optimizations (needed for realtime
- : use) for many different GfxBoards, to let anyone use his routines as well.
-
- Usually new methode are invented to overcome the shortcomming of the HW.
- Demo on the otherhand want to also push HW to its limit too...
-
- Having an open API & device system will please everyone. You can still
- bang the documented HW for demos or extending the API functionality for
- that HW device. If you care to work on past & future system you will
- use the API functionality only at the minimum functionality it offer,
- like 'gfx Level0' functionality. If you find yourself in need to play
- long realtime clip as game interludes you can make them available to people
- having at least 'video level0' functionality that could include
- realtime mpeg decoding at set resolution. etc.. etc..
-
- : Good for GNU; nothing to do with games/demos, because (and I am one of the
- : people really sorry about it) this kind of "Communism" doesn't work in this
- : field, because you get fucked everytime you try to be generous, while the
- : others dont do it but just exploit others work. Communism works among
- : Communists, not among parassites, and who *invents* rather than use or copy
- : others' work, will never let parassites exploit him so easily. People tend
- : to confuse Communism with "some work some don't", while it is "we all work
- : together". The first option is just another kind of capitalism. This is the
- : same for games/demos coding, where there's a software evolution or revolution
- : every time the last stunning new routine is released (not often last times..).
-
- I agree, I dont see why a game developer will propose his API
- extension for free to other game developer. 3d game engine on PC
- dont come for free...
- But SGI seem to share (for $ I guess) their ideas...
-
- Stephan
-